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Abstract 


Modern  aircraft  increasingly  rely  on  electric  power  for  subsys¬ 
tems  that  have  traditionally  run  on  mechanical  power.  The 
complexity  and  safety-criticality  of  aircraft  electric  power  sys¬ 
tems  have  therefore  increased,  rendering  the  design  of  these 
systems  more  challenging.  This  work  is  motivated  by  the 
potential  that  correct-by-construction  reactive  controller  syn¬ 
thesis  tools  may  have  in  increasing  the  effectiveness  of  the  elec¬ 
tric  power  system  design  cycle.  In  particular,  we  have  built 
an  experimental  hardware  platform  that  captures  some  key 
elements  of  aircraft  electric  power  systems  within  a  simplified 
setting.  We  intend  to  use  this  platform  for  validating  the  ap¬ 
plicability  of  theoretical  advances  in  correct-by-construction 
control  synthesis  and  for  studying  implementation-related 
challenges.  We  demonstrate  a  simple  design  workflow  from 
formal  specifications  to  auto-generated  code  that  can  run 
on  software  models  and  be  used  in  hardware  implementa¬ 
tion.  We  show  some  preliminary  results  with  different  control 
architectures  on  the  developed  hardware  testbed. 
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1  Introduction  and  Motivation 

Aircraft  electric  power  systems  have  become  increasingly  important  over 
the  years  because  they  support  various  subsystems  and  essential  services  on 
aircraft.  These  electrical  services  and  subsystems  are  commonly  referred  to 
as  system  loads.  System  loads  are  of  two  categories,  namely,  primary  loads 
(some  of  these  are  safety-  or  mission-critical)  and  secondary  (noncritical) 
loads.  The  system  needs  to  ensure  that  the  primary  loads  are  supplied  with 
power  at  all  times;  that  is,  if  a  fault  affects  a  part  of  the  system  that  powers  a 
primary  load,  the  system  must  be  able  to  reconfigure  and  provide  power  to  the 
load  through  another  path.  In  order  to  reconfigure  a  system,  it  is  necessary 
to  reroute  power,  which  is  accomplished  with  high  power  electromagnetic 
devices  called  contactors.  The  contactors  are  arranged  such  that  they  are 
magnetically  held  in  a  preferred  state  by  an  applied  signal.  The  state  is  either 
open  or  closed.  To  reconfigure  the  contactors  to  react  to  faults  and  modes 
of  operation,  the  system  uses  control  logic  that  can  sense  system  conditions 
and  environmental  conditions  under  which  the  system  operates.  The  electric 
power  system,  therefore,  includes  voltage  and  current  sensors  connected  to 
the  control  logic.  In  current  practice,  the  control  logic  is  often  designed  by 
hand,  resulting  in  lengthy  design  and  verification  cycles.  As  an  alternative 
approach,  [1]  and  [2]  explored  the  application  of  correct-by-construction 
reactive  controller  synthesis  techniques. 

In  this  report,  we  describe  our  recently  developed  simulation  models  and 
a  hardware  testbed  for  validating  reactive  controllers  synthesized  using  TuLiP 
[1],  a  temporal  logic  planning  toolbox,  in  order  to  investigate  the  validity 
of  the  assumptions  made  in  controller  synthesis.  TuLiP  is  a  collection  of 
Python-based  code  used  for  automatic  synthesis  of  correct-by-construction 
embedded  control  software.  Automatic  synthesis  of  reactive  centralized  and 
distributed  controllers  of  aircraft  electric  power  systems  is  described  in  detail 
in  [2].  The  particular  distributed  synthesis  method  adopted  in  this  study  is 
introduced  in  [3]  and  [4]. 

University-scale  testbeds  for  research  on  correct-by-construction  controller 
synthesis  are  fairly  limited.  An  advanced  diagnostics  and  prognostics  testbed 
is  described  in  [5].  Some  applications  of  this  testbed  to  the  electric  power 
systems  of  spacecraft  and  aircraft  are  detailed  in  [6].  However,  the  experi¬ 
ments  focused  on  diagnostic  queries  of  the  system,  while  our  work  is  focused 
on  the  implementation  of  correct-by-construction  control  protocols  for  fault- 
tolerant  operations.  A  robotics  testbed  implementing  correct-by-construction 
controllers  is  described  in  [7]. 

TuLiP  can  be  used  to  synthesize  logic  so  that  the  satisfaction  of  certain 
safety  requirements  is  guaranteed.  The  synthesized  logic  enables  the  contac¬ 
tors  to  react  to  changes  in  system  conditions  such  as  the  status  of  generators 
and  rectifier  units.  This  is  commonly  referred  to  as  a  reactive  system.  The 
safety  requirements  used  in  our  simulation  models  and  hardware  testbed 
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Figure  1:  Single-line  diagram  of  the  power  system  testbed.  Contactors  are  represented 
by  double  bars.  The  AC  and  DC  sides  of  the  system  are  separated  by  rectifier 
units  (RU). 

stipulate  that  the  alternating  current  generators  should  never  be  paralleled 
and  that  the  duration  for  which  the  bus  is  not  powered  should  never  exceed 
a  certain  limit.  They  also  include  the  environment-related  assumption  that 
at  least  a  subset  of  the  generators  and  rectifier  units  must  be  working  at  all 
times.  The  simulation  models  were  built  with  the  physical  modeling  software 
SimPowerSystems,  an  extension  of  Simulink  [8].  In  order  to  validate 
the  controller  on  the  experimental  hardware  platform,  we  synthesized  and 
tested  it  using  TuLiP  and  SimPowerSystems,  respectively.  Thereafter,  we 
investigated  the  validity  of  the  assumptions  used  for  controller  synthesis  on 
the  experimental  hardware  platform. 

An  aircraft  electric  power  system  uses  different  voltage  levels,  which  can 
broadly  be  divided  into  four  categories,  namely,  high-voltage  AC,  high-voltage 
DC,  low-voltage  AC,  and  low-voltage  DC.  The  topology  in  Figure  1  is  of 
specific  interest  because  it  is  representative  of  some  of  the  key  features  of 
aircraft  electric  power  systems  in  simplified  settings.  Therefore,  the  hardware 
testbed  was  built  based  on  the  above  mentioned  topology. 
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2  Theoretical  Background 

We  now  discuss  the  formal  specification  language  utilized  for  the  synthesis  of 
control  protocols  and  how  these  protocols  are  implemented  in  the  software 
models  and  on  the  hardware  testbed. 

2.1  Linear  Temporal  Logic 

In  reactive  systems,  correctness  depends,  not  only  on  inputs  and  outputs  of 
a  computation,  but  on  execution  of  the  system.  Temporal  logic  is  a  branch 
of  logic  that  incorporates  temporal  aspects  to  reason  about  propositions  in 
time.  In  this  report,  we  consider  a  version  of  temporal  logic  called  linear 
temporal  logic  (LTL)  [9]. 

LTL  includes  Boolean  connectors  like  negation  (->),  disjunction  (V), 
conjunction  (A),  material  implication  (—>•),  and  two  basic  temporal  modalities 
next  (O)  and  until  (  ).  By  combining  these  operators,  it  is  possible  to 

specify  a  wide  range  of  requirements.  Formulas  involving  other  operators  can 
be  derived  from  these  basic  ones,  including  eventually  (O)  and  always  (□). 

An  atomic  proposition  is  a  statement  on  system  variables  v  that  has  a 
unique  truth  value  ( True  or  False)  for  a  given  value  v.  For  a  set  %  of  atomic 
propositions,  any  atomic  proposition  p  E  k  is  an  LTL  formula.  Given  a 
propositional  formula  describing  properties  of  interest,  widely  used  temporal 
specifications  can  be  defined  in  terms  of  their  corresponding  LTL  formulas  as 
follows.  A  safety  formula  asserts  that  a  property  will  remain  true  throughout 
the  entire  execution  (i.e.,  nothing  bad  will  happen).  A  response  formula 
states  that  at  some  point  in  the  execution  following  a  state  where  a  property  is 
true,  there  exists  a  point  where  a  second  property  is  true.  A  response  formula 
is  used  to  describe  how  systems  need  to  react  to  changes  in  environment 
or  operating  conditions.  A  response  property,  for  example,  can  be  used  to 
describe  how  the  system  should  react  to  a  generator  failure:  if  a  generator 
fails,  then  at  some  point  a  corresponding  contactor  should  open  [1],  [2], 

2.2  Reactive  Synthesis 

A  system  consists  of  a  set  V  of  variables.  The  domain  of  V,  denoted  by 
domfV),  is  the  set  of  valuations  of  V.  Let  E  and  P  be  sets  of  environment 
and  controlled  variables,  respectively.  Let  s  =  (. e,p )  6  dom(E)  x  dom(P)  be 
a  state  of  the  system.  Consider  a  LTL  specification  <p  of  assume-guarantee 
form 

<P  =  <Pe  ->  <Ps, 

where,  roughly  speaking,  (pe  characterizes  the  assumptions  on  the  environment 
and  (ps  characterizes  the  system  requirements.  LTL  formulas  are  interpreted 
over  infinite  sequences  of  states,  where  •  •  •  *s  an  infinite  sequence  of 

valuations  of  environment  and  controlled  variables.  The  synthesis  problem 
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is  then  concerned  with  constructing  a  strategy,  i.e.,  a  partial  function  /  : 
($0^1  •  •  -St-i,et)  i-a  pt,  which  chooses  the  move  of  the  controlled  variables  based 
on  the  state  sequence  so  far  and  the  behavior  of  the  environment  so  that  the 
system  satisfies  (ps  as  long  as  the  environment  satisfies  (pe. 

For  general  LTL,  the  synthesis  problem  has  a  doubly  exponential  com¬ 
plexity  [10].  A  subset  of  LTL,  namely  generalized  reactivity  (2.2)  (GR(1)), 
can  be  solved  in  polynomial  time  (polynomial  in  the  number  of  valuations 
of  the  variables  in  E  and  P )  [11].  GR(1)  specifications  restrict  (pe  and  (ps  to 
take  the  following  form,  for  a  €  {e,s}, 

(Pa  ■■=  K it  A  /\  □?“«  A  /\  nO(p?j , 

«€/{*  !€/“ 

where  <p“lit  is  a  propositional  formula  characterizing  the  initial  conditions;  <p“- 
are  transition  relations  characterizing  safe,  allowable  moves  and  propositional 
formulas  characterizing  invariants;  and  <p“.  are  propositional  formulas  charac¬ 
terizing  states  that  should  be  attained  infinitely  often.  For  the  specifications 
considered  in  this  report,  the  safety  fragment  of  GR(1)  suffices. 

Given  a  GR(1)  specification,  the  digital  design  synthesis  tool  implemented 
in  JTLV  (a  framework  for  developing  temporal  verification  algorithm)  [12] 
generates  a  finite-state  automaton  that  represents  a  switching  strategy  for 
the  system.  TuLiP  provides  an  interface  to  JTLV. 

2.3  Testbed  Specifications 

Consider  the  single-line  diagram  in  Figure  1  in  which  environment  variables 
are  health  statuses  of  generators  and  rectifier  units,  and  controlled  variables 
are  the  state  of  contactors.  Consider  also  two  different  controller  implemen¬ 
tations:  a  centralized  logic  that  runs  the  system  with  a  single  automaton  and 
a  distributed  logic  that  has  two  different  automata,  one  for  the  AC  subsystem 
and  one  for  the  DC  subsystem,  running  sequentially. 

For  the  centralized  logic,  the  environment  assumptions  are:  (i)  at  least 
one  generator  must  always  be  healthy,  and  (ii)  at  least  one  rectifier  unit  must 
always  be  healthy.  In  LTL,  this  can  be  written  as 

E\(((gen\  =  healthy )  V  (gem  =  healthy ))  A 
((rui  =  healthy)  V  (ru 2  =  healthy))), 

where  gen\,  gem ,  ru  \ ,  and  m2  are  health  statuses  of  the  two  generators 
and  the  two  rectifier  units,  respectively.  To  ensure  non-paralleling  of  AC 
sources,  we  disallow  any  configuration  of  contactors  in  which  a  path  may  be 
created  between  the  two  generators.  The  contactors  c\  and  ct  are  below  the 
generators  in  Figure  1,  and  C3  is  between  the  AC  buses.  Therefore,  contactors 
c\,C2i  and  C3  can  never  be  closed  at  the  same  time.  This  is  written  as 


□-.((ci  =  closed)  A  (C2  =  closed)  A  (C3  =  closed)). 
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The  last  specification  ensures  that  all  buses  can  be  unpowered  for  no  more 
than  a  time  T.  The  limit  that  unpowered  time  can  be  set  to  depends  on  timing 
characteristics  of  the  testbed,  witch  is  explained  in  Section  4.1.  To  synthesize 
centralized  logic,  we  used  the  assumption  that  this  time  is  zero;  thus,  the 
specifications  that  all  buses  ft,  fulfill  □(£>,■  =  powered ),  for  i  £  {1,2, 3, 4}  can 
be  set. 

To  synthesize  distributed  logic,  we  separate  the  system  into  two  subsys¬ 
tems,  seen  in  Figure  1.  The  AC  subsystem  contains  all  AC  components 
(generators,  AC  contactors,  AC  buses,  and  loads).  The  DC  subsystem  con¬ 
tains  all  rectifier  units,  DC  contactors,  buses,  and  loads.  All  specifications 
from  the  centralized  case  decompose  and  carry  over  to  the  distributed  case. 
However,  in  order  to  ensure  that  the  overall  specification  is  realizable,  we 
impose  additional  restrictions  on  the  components  located  at  the  interface 
between  subsystems. 

The  rectifier  units  contain  capacitors  that  can  be  chosen  so  that  they 
create  a  delay  Tru,  in  which  the  DC  buses  stays  powered  even  after  that  an 
AC  bus  gets  mipowered. 

If  Tru  >  T  the  additional  interface  refinement  comes  in  the  form  of  a 
guarantee  specification  that  all  DC  buses  ft,- ,  for  i  £  {1,2}  will  always  be 
powered  □  (&,■  =  powered ),  provided  that  both  rectifier  units  stay  healthy,  i.e. , 

□  ((rwi  =  healthy)  A  {rui  =  healthy)). 

This  guarantee  is  written  as  an  environment  for  the  DC  subsystem.  With 
this  refinement,  both  subsystems  can  be  synthesized  independently,  and  the 
overall  system  specifications  are  satisfied  when  they  are  implemented  together. 
We  assume  that  the  time  a  generator  remains  healthy  is  not  arbitrarily  short 
so  that  the  AC  bus  powered  time  (i.e.,  the  time  between  two  intervals  when 
AC  bus  is  unpowered)  is  large  enough  to  keep  the  capacitors  on  rectifier  units 
charged. 

2.4  Implementing  Formal  Specifications 

TuLiP  generates  finite-state  automata  in  the  form  of  a  text  file  that  enu¬ 
merates  the  possible  states  of  the  system  and  how  the  transitions  could 
be  carried  out  according  to  the  current  state.  It  also  generates  a  text  file 
that  specifies  environment  variables  (e.g.,  generators  and  rectifier  units) 
and  system  variables  (e.g.,  contactors).  In  order  to  implement  the  control 
logic  in  SimPowerSystems,  we  automatically  translate  these  files  into  a 
MATLAB-compatible  script.  A  preliminary  solution  uses  a  Python  script  for 
this  translation.  A  Python  script  generating  the  Matlab  code  is  released 
with  TuLiP  version  0.3c  under  the  tools  directory1. 

1http : //tulip- control . sf .net 
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State  0  <genl:l,  gen2:l,  cl :  1 ,  c2:l,  c3:0> 
With  successors:  1,  2,  3,  0 
State  1  <genl:0,  gen2:0,  cl:0,  c2:0,  c3:0> 
With  no  successors 

State  2  <genl:0,  gen2:l,  cl :  1 ,  c2:0,  c3:l> 
With  successors:  1,  2,  3,  0 
State  3  <genl:l,  gen2:0,  cl:0,  c2:l,  c3:l> 
With  successors:  1,  2,  3,  0 


Figure  2:  Sample  of  a  TuLiP  output  in  two-generator  and  three-contactor  case.  The 
generator  status  variables  are  genl  and  gen2,  and  the  contactor  status  variables 
are  cl,  c2,  and  c3.  Each  state  has  successors,  which  define  where  the  controller 
can  transit  depending  on  current  state.  In  addition,  no-successor  states  exist. 


function  [cl,  c2,  c3]  =  mscript(genl,  gen2) 
global  state; 
switch  (state) 
case  0: 

if  genl  ==  1  and  gen2  ==  1  then 
state  =  0;  cl  =  1;  c2  =  1;  c3  =  0; 
else  if  genl  ==  0  and  gen2  ==  0  then 
state  =  1;  cl  =  0;  c2  =  0;  c3  =  0; 

end  if 
case  1: 

end  switch 

Figure  3:  Sample  code  generated  using  TuLiP  controller  shown  in  Figure  2. 


Figure  2  shows  an  example  four-state  TuLiP  generated  controller  for  the 
two-generator  and  three-contactor  case.  A  few  lines  of  the  auto-generated 
code  that  corresponds  to  this  controller  is  shown  in  Figure  3.  The  auto¬ 
generated  code  can  be  inserted  in  SimPowerSystems  as  a  Matlab  function 
block.  It  can  also  be  connected  to  the  board  with  the  code  shown  in  Figure  4. 
The  complete  version  of  the  code  in  Figure  4  is  given  in  Appendix  A.  An 
example  of  how  a  SimPowerSystems  model  can  look  like  is  shown  in 
Figure  5. 
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global  state; 
while  1  do 

genl  =  readgenl(); 
gen2  =  readgen2(); 

[cl,  c2,  c3]  =  mscript(genl,  gen2); 
writeboard(cl,  c2,  c3); 
end  while 

Figure  4:  Code  that  implements  the  control  software  running  on  hardware  model. 


Figure  5:  An  example  of  how  a  SimPowerSystem  model  can  look  like.  This  model 
corresponds  to  the  AC  subsystem  shown  in  Figure  1. 


Design  and  Implementation 


3  Design  and  Implementation 

The  single-line  diagram  in  Figure  1  is  a  simplified  notation  for  representing 
a  three-phase  power  system.  However,  as  described  in  Section  3.1,  power 
supply  to  the  hardware  testbed  is  not  three-phase.  In  order  to  represent 
the  installations  of  the  sensors,  circuit  protection  devices,  and  fault  injec¬ 
tion  switches,  we  present  a  detailed  schematic  of  the  testbed  in  Figure  6. 
Descriptions  of  the  components  shown  in  Figure  6  are  given  in  Figure  7. 

The  hardware  testbed  has  two  different  voltage  levels:  24  VAC  and  2.5 
VDC.  The  DC  section  is  connected  to  the  AC  section  by  rectifier  units. 
Aircraft  contactors  are  designed  to  switch  three-phase  electric  power  with 
relatively  high  currents.  Relays  are  generally  used  for  switching  lower  currents. 
These  operate  in  a  similar  fashion  to  contactors  but  are  lighter,  simpler,  and 
less  expensive.  Therefore,  it  was  more  convenient  to  handle  the  switching  in 
the  hardware  model  with  relays.  It  was  possible  to  connect  the  control  logic  to 
the  relays  with  the  use  of  a  relay  board2,  which  is  a  set  of  computer-controlled 
relays  that  can  communicate  with  programming  languages  supporting  serial 
communications,  e.g.,  Matlab.  Analog-to-digital  (A/D)  connections  on  the 
relay  board  are  used  to  monitor  the  system  conditions.  A  photo  of  the  setup3 
is  shown  in  Figure  8.  The  transformers  in  Figure  8  are  connected  to  power 
cords;  these  can  be  unplugged  to  simulate  a  generator  failure.  The  rectifier 
units  are  connected  to  a  switch,  which  can  be  used  to  generate  a  fault  on  the 
DC  subsystem.  An  explicit  component  list  for  the  hardware  testbed  is  listed 
in  Appendix  B.  Next,  we  describe  how  we  monitor  and  sense  the  status  of 
generators  and  rectifier  units. 

3.1  Generation  and  Circuit  Protection 

Each  generation  unit  consists  of  a  12  V  battery  connected  to  an  inverter 
that  generates  120  VAC;  that  is  then  transformed  down  to  24  VAC  to  ensure 
safety.  If  the  controller  violates  one  of  the  safety  requirements  and  connects 
these  two  sources  in  parallel,  it  would  result  in  a  short-circuit  and  cause  the 
fuses  installed  next  to  the  generators,  shown  in  Figure  6(a),  to  blow.  This 
observation  makes  it  possible  to  monitor  the  correctness  of  the  controllers  at 
run  time. 

3.2  Sensing 

The  relay  board  needs  to  react  consistently  to  faults  injected  into  the  system; 
this  requirement  implies  that  sensor  placement,  functionality,  accuracy,  and 

2  A  company  called  RelayPROS  sells  such  relay  boards.  For  more  information,  visit 
www . relaypros . com . 

3 A  photo  of  the  relay  board  can  be  found  online  at  assets.controlanything.com/ 
photos/usb_relay/ZADSR165DPDTPR0XR_USB-900 . jpg 
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(b)  Sensing  configuration 

Figure  6:  Circuit  schematic  of  the  hardware  testbed,  which  corresponds  to  the  single-line 
diagram  shown  in  Figure  1.  The  numbered  arrows  in  (a)  denote  voltage  sensing 
connections  to  the  corresponding  numbered  arrows  in  (b). 
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Figure  7:  Description  of  the  components  used  in  Figure  6. 
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Figure  8:  Hardware  setup  corresponding  to  the  single-line  diagram  shown  in  Figure  1. 
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time  delay  play  crucial  roles  in  design.  Two  types  of  faults  can  be  injected 
in  the  system,  namely,  rectifier  unit  failures  and  generator  failures.  Voltage 
sensing  for  generator  failures  is  handled  using  additional  relays.  These  relays 
close  a  3.6  V  circuit  to  a  battery  when  triggered  by  the  voltage  from  the 
transformers.  If  a  fault  occurs  and  a  generator  does  not  work  properly,  the 
3.6  V  circuit  opens  and  the  system  reacts  accordingly.  The  voltage  sensors 
of  the  rectifier  units  are  directly  connected  to  the  A/D  ports  of  the  relay 
board  because  the  voltage  can  be  tuned  to  the  appropriate  value  using  an 
adjustable  output  on  the  rectifier  units.  Figure  6(b)  illustrates  the  sensing 
configuration. 
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4  Experiments 

We  next  describe  the  characteristics  of  the  hardware  testbed  and  show  some 
preliminary  test  runs  with  different  control  architectures. 

4.1  Testbed  Characteristics 

The  first  step  before  the  implementation  and  testing  of  different  controllers 
is  characterizing  the  timing  properties  of  the  hardware  testbed.  Every  relay 
has  a  time  delay  between  the  time  a  command  is  sent  by  the  computer  and 
the  time  an  action  (i.e. ,  relay  opening  or  closing)  is  taken,  this  is  referred 
to  as  the  relay  delay  time ,  7)/.  Furthermore,  the  system  has  delays  resulting 
from  control  cycle  times ,  Tc  and  7)f,  defined  as 

T-  =  T'+T,+T’ 

a). 

where  Tr  is  the  time  it  takes  to  read  the  health  statuses  from  all  of  the  four 
environment  variables,  7}  is  the  time  it  takes  to  run  the  logic  (the  time  can 
be  interpreted  as  the  time  taken  to  run  the  code  shown  in  Figure  3),  and  Tw 
is  the  time  it  takes  to  write  information  to  the  board  (see  Figure  4).  Writing 
information  to  the  board  is  not  needed  in  every  iteration  (for  instance,  if  the 
system  state  remains  the  same),  therefore  the  control  cycle  time  also  include 
T' 

c 

The  control  cycle  times  Tc  and  T'c  are  listed  in  Table  1.  The  relay  delay 
time  can  be  found  from  the  board  specifications  and  shall  be  less  than  20ms. 

An  important  safety  requirement  in  an  aircraft  is  that  a  bus  should  never 
lose  power  for  more  than  a  certain  duration,  e.g.,  typically  50ms.  In  the 
hardware  testbed,  the  time  for  which  the  bus  is  unpowered  depends  on  the 
control  cycle  times  and  the  relay  delay  time,  and  because  the  control  cycle 
times  exceed  50ms,  we  cannot  use  the  typically  specified  time  for  which  an 
aircraft  can  be  unpowered.  Therefore,  it  was  necessary  to  adopt  a  suitable 
limit.  As  illustrated  with  two  environment  variables  in  Figure  4  the  relay 
board  read  the  health  status  from  each  environment  variable  in  a  specified 
order.  It  is  therefore  necessary  to  include  a  part  of  T'c  from  the  previous 
control  cycle  in  this  limit.  The  time  7}  in  Equation  (2)  is  negligible  compared 


Tc  [ms] 

Tc  [ms] 

Mean 

303.7 

187.5 

Max 

333.3 

234.1 

Min 

282.5 

166.6 

Table  1:  Control  cycle  time,  both  when  relay  configuration  changes,  i.e.,  Tc  and  without 
any  change,  i.e.,  T'c.  The  values  with  and  without  change  were  calculated  from 
20  and  250  measurements,  respectively. 
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to  Tr  and  Tw ,  the  time  taken  to  read  the  health  status  from  one  environment 
variable  can  therefore  be  approximated  as  T'c /A.  A  reasonable  value  of  an 
acceptable  unpowered  time  for  the  hardware  testbed  can  be 

T  ss  max  ( Tj )  +  max  (Tc)  +  - —  —  max  (T'),  (3) 

where  n  6  {1,2, 3, 4}  is  the  number  which  denotes  the  order  of  when  the 
environment  variable  that  is  faulty  is  read  in  the  code. 

4.2  Controller  Tests 

Two  controllers  were  tested,  one  with  distributed  logic  and  one  with  central¬ 
ized  logic.  The  controller  with  centralized  logic  had  a  16-state  automaton 
synthesized  as  explained  in  Section  2.3.  The  controller  with  distributed  logic 
had  two  four-state  automata  that  run  on  each  subsystem.  Both  of  these 
automata  were  synthesized  in  a  similar  fashion  to  the  16-state  controller. 

If  the  environment-related  assumption  is  violated,  the  controller  may  end 
up  in  a  state  with  no  outgoing  transitions,  referred  to  as  the  no-successor 
state.  The  environment-related  assumptions  for  the  testbed  are  expressed 
in  Equation  (1)  of  Section  2.3.  A  violation  of  Equation  (1)  results  in  the 
controller  entering  a  no-successor  state,  which  happens  when  both  generators 
or  both  rectifier  units  are  faulty.  If  a  centralized  controller  senses  that 
both  rectifier  units  are  faulty,  the  whole  system  stops  working  because  a 
no-successor  state  has  been  reached.  This  is  not  the  case  when  distributed 
logic  is  used,  because  the  AC  system  continues  working  even  if  the  DC 
environment  assumption  is  violated  and  the  DC  part  reaches  a  no-successor 
state.  The  distributed  logic  implementation  has  two  different  automata  that 
represent  the  logic,  one  for  each  subsystem,  with  coupling  between  them. 
However,  the  distributed  logic  is  centralized  in  that  it  consists  of  single 
control  software  running  on  a  single  computer  and  communicating  with  the 
hardware  through  a  single  channel. 

Figure  9  shows  the  voltage  measurement  for  the  centralized  16-state 
controller.  The  measurement  was  taken  on  the  AC  bus  when  the  generator, 
which  health  status  is  read  at  second  place  (n  =  2  in  Equation  (3))  of 
the  four  environment  variables  in  the  code,  was  switched  off  and  then  on 
again.  The  generator  was  switched  off  at  t  =  2.83s,  at  which  point  the  bus 
becomes  unpowered.  The  second  vertical  line  from  the  left  indicates  when 
the  controller  reacts  and  power  up  the  bus  using  the  other  generator,  which 
happens  at  t  =  3.1s.  The  generator  was  switched  on  again  at  t  =  3.73s;  this 
was  accompanied  by  a  discernible  change  in  the  sine  curve.  Once  a  generator 
is  switched  on  again  after  a  fault,  the  time  for  which  the  bus  is  without 
power  is  not  noticeable  because  the  controller  sends  simultaneous  commands 
to  two  relays. 

The  measured  bus- unpowered  times  are  listed  in  Table  2,  which  show 
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3,2  3,3  3,4 

Time  [s] 


Figure  9:  Bus  voltage  measurement  when  a  generator  is  switched  off  and  then  turned 
back  on.  The  first  vertical  line  indicates  the  fault,  the  second  vertical  line  is 
when  the  controller  reacts,  and  the  third  line  is  when  the  generator  is  turned 
back  on. 


Bus-unpowered  time  [ms] 

Mean 

333.9 

Max 

414.9 

Min 

232.7 

Table  2:  Time  for  which  bus  is  unpowered  after  a  fault  is  injected.  These  values  are 
calculated  using  measurements  from  10  fault  injections. 


a  maximum  value  of  Tmax  =  414.9ms.  An  acceptable  unpowered  time  when 
n  =  2  and  max(7j)  =  20ms  can  be  calculated  with  Equation  (3).  It  follows 
that  T  «  max  (7^)  +  max  (Tc)  +  \  max  (T'c)  =  470.35ms  and  hence,  Tmax  <  T.  We 
used  a  digital  storage  oscilloscope  (Rigol  DS1052E  50MHz)  for  measurements. 
The  measurement  data  are  imported  into  Matlab  to  plot  sinusoidal  curves 
(e.g.,  Figure  9)  and  to  analyze  the  signal  to  estimate  the  unpowered  times. 
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5  Limitations  and  Extensions 

As  discussed  earlier,  when  we  implemented  distributed  logic  with  the  hardware 
model,  it  was  still  centralized  in  that  only  one  relay  board  was  connected  to 
one  computer.  However,  it  is  possible  to  use  two  relay  boards  connected  to 
two  different  computers,  with  each  of  them  controlled  by  different  automata. 
The  part  that  contributes  the  most  to  the  control  cycle  times  (Tc  and  7^),  is 
the  time  it  takes  to  read  data  from  the  board  (Tr);  if  the  controller  is  operated 
with  two  relay  boards,  Tr  would  be  split  in  half,  which  would  cause  Tc  and  T'c 
to  decrease  significantly.  The  distributed  control  architecture  would  also  be 
more  like  that  of  an  aircraft. 

We  injected  faults  in  the  hardware  testbed  by  unplugging  the  power  cords 
and  changing  the  switches;  however,  a  more  accurate  approach  to  generate 
faults  would  be  the  use  of  an  additional  relay  board.  Using  an  additional 
fault  injection  board,  we  can  systematically  study  synchronous,  correlated, 
and  cascaded  failures  and  their  influence  on  controller  performance;  with 
the  current  method  of  fault  injection,  it  could  be  difficult  to  switch  off  a 
generator  and  a  rectifier  unit  within  the  same  control  cycle. 

On  an  aircraft,  the  controller  is  an  embedded  system  designated  for 
a  specific  task.  To  increase  its  reliability  and  performance,  the  hardware 
model  could  be  adapted  to  run  the  relay  boards  through  microcontrollers. 
Embedded  code  for  these  microcontrollers  can  be  readily  generated  using 
Matlab. 

At  last,  we  want  to  emphasize  the  fact  that  it  is  entirely  possible  to 
synthesize  the  controller  with  another  synthesis  tool  and  test  it  on  the 
testbed.  It  was  convenient  as  an  initial  demonstration  to  choose  LTL, 
reactive  synthesis,  and  TuLiP  because  they  have  been  applied  to  electric 
power  systems  in  the  past  [2]. 
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A  Code  to  Implement  Control  Software 

The  code  below  shows  how  the  control  software  can  be  implemented  on  the 
hardware  testbed  when  the  board  from  RelayPROS  is  used.  The  numbers 
on  the  relays  in  Figure  10  are  the  same  as  they  have  to  be  connected  when 
controlling  the  board  through  MATLAB  with  the  code  below.  The  numbers 
range  from  0  to  7,  i.e.,  eight  relays  in  total  for  each  relay  bank.  There  are 
two  relay  banks  on  the  relay  board,  i.e.,  16  relays  in  total.  The  models  built 
in  this  report  only  use  Relay  Bank  1. 


Figure  10:  Circuit  schematic  of  the  hardware  testbed,  which  corresponds  to  the  single-line 
diagram  shown  in  Figure  1. 
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clc 

clear 

global  state; 
global  stateDC; 
state  =  0; 
stateDC  =  0; 

/(choose  the  correct  COM  port  for  the  computer  in  use. 

s=serial ( ’ COM3  * ) ; 

set (s , ’BaudRate ’ , 115200) 

f open(s) 

°/,Set  initial  status 
f write (s, 254) 
fwrite(s,8) 
fread(s, 1)  ; 
f write (s, 254) 
f write (s, 15) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 3) 
fread(s, 1) ; 
f write (s, 254) 
fwrite(s,9) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 10) 
fread(s, 1) ; 
f write (s, 254) 
fwrite(s,4) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 14) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 13) 
fread(s, 1) ; 

°/,read  relay  status 

f write (s, 254) 

f write (s, 16) 

c2a  =  fread(s,l); 

f write (s, 254) 

f write (s, 23) 

cla  =  f read(s , 1) ; 

f write (s, 254) 

f writers, 19) 

c3a  =  fread(s,l); 

f write (s, 254) 

f write (s, 17) 

c4a  =  fread(s,l); 

f write (s, 254) 

f write (s, 18) 

c5a  =  fread(s,l); 

f write (s, 254) 

f write (s, 20) 

c6a  =  fread(s,l); 

disp( ’ [cl , c2, c3, c4, c5, c6]  =  ’) 

disp([cla,c2a,c3a,c4a,c5a,c6a] ) 

statecount=0; 

count =1 ; 

pause (1) 

disp(’ start’) 

disp(’ - ’) 

disp (’system  runs  normal’) 
disp(state) 

°/,If  distributed  control  logic  is  used 
/(uncomment  the  following  row 
/(disp  (stateDC) 
while  count<100 
tic 

f write (s ,254) ; 
fwrite(s, 150) ; 
leftg  =  fread(s,l); 
f write (s, 254) ; 
fwrite(s, 151) ; 
rightg  =  fread(s,l); 
f write (s, 254) ; 
fwrite(s, 152) ; 
leftru  =  fread(s,l); 
f write (s ,254) ; 
fwrite(s, 153) ; 
right ru  =  fread(s,l); 
if  rightg>100  &&  rightg<200 
rgen  =  1; 

else 

rgen  =  0; 

end 

if  lef tg>100  &&  lef tg<200 
lgen  =  1; 

else 

lgen  =  0; 

end 

if  rightru>100  &&  rightru<200 
rru  =  1; 

else 

rru  =  0; 

end 

if  leftru>100  &&  leftru<200 
lru  =  1; 

else 


lru  =  0; 

end 

stateprev=state ; 

°/,Reads  the  controller  BPCU.m 
% (comment  if  distributed  logic  is  used) 
[cl,c2,c3,c4,c5,c6]  =  BPCU (rgen, lgen, rru, lru) ; 
°/,If  distributed  control  logic  is  used 
°/,uncomment  the  following  rows 
"/0[cl,c2,c3]  =  BPCUAC (rgen, lgen)  ; 

7,[c4,c5,c6]  =  BPCUDC(rru,lru)  ; 
if  cl  ~=  cla  ||  c2  ~=  c2a  I  I  c3  ~=  c3a  I  I . . . 
c4  ~=  c4a  II  c5  ~=  c5a  j I  c6  ~=  c6a 
t=l ; 

statecount=statecount+l ; 

else 


t=0; 

end 

if  stateprev  ~=state 

disp ( ’ - 

if  rgen==0 

di sp ( ’ rgen  unhealthy ’ ) 

end 

if  lgen==0 

disp (’lgen  unhealthy’) 

end 

if  lru==0 

disp(’lru  unhealthy’) 

end 

if  rru==0 


disp (’rru  unhealthy’) 

end 


if  rru==l  kk  lru==l  kk  rgen==l  kk  lgen==l 
disp(’ system  runs  normal’) 

end 

disp (’ current  state’) 
disp(state) 

%If  distributed  control  logic  is  used 
°/0uncomment  the  following  row 
°/0disp(  stateDC) 

end 

f write (s, 254) ; 
f write (s, 26) ; 
f read(s , 1) ; 
if  cl  ~=  cla 
if  cl==l 

f write (s, 254) 
f write (s, 15) 
fread(s , 1) ; 

else 

f write (s, 254) 
fwrite(s,7) 
fread(s , 1) ; 

end 

f write (s, 254) 

fwrite(s,23) 

cla  =  fread(s , 1) ; 

end 


if  c2  ~=  c2a 


if  c2==l 

f write (s, 254) 
fwrite(s,8) 
f read(s , 1) ; 

else 

f write (s, 254) 
f write (s,0) 
fread(s , 1) ; 

end 

f write (s, 254) 
fwrite(s, 16) 
c2a  =  fread(s,l); 

end 

if  c3  ~=  c3a 
if  c3==l 

f write (s, 254) 
fwrite(s,ll) 
f read(s , 1) ; 

else 

f write (s, 254) 
f write (s, 3) 
f read(s , 1) ; 

end 

f write (s, 254) 
fwrite(s, 19) 
c3a  =  fread(s,l); 

end 

if  c4  ~=  c4a 
if  c4==l 

f write (s, 254) 
fwrite(s, 14) 
f read(s , 1) ; 

else 

f write (s, 254) 
f write (s, 6) 
f read(s , 1) ; 

end 

f write (s, 254) 
f write (s, 22) 
c4a  =  fread(s,l); 
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end 

if  c5  ~=  c5a 
if  c5==l 

f write (s, 254) 
fwrite(s, 13) 
f read(s , 1) ; 

else 

f write (s, 254) 
f write (s, 5) 
f read(s , 1) ; 

end 

f write (s ,254) 

fwrite(s,21) 

c5a  =  fread(s,l); 

end 

if  c6  c6a 
if  c6==l 

f write (s, 254) 
fwrite(s, 12) 
f read(s , 1) ; 

else 

f write (s, 254) 
f writers, 4) 
f read(s , 1) ; 

end 

f write (s, 254) 
f write (s, 20) 
c6a  =  fread(s,l); 

end 

f write (s, 254) ; 
f write (s, 37) ; 
f read(s , 1)  ; 
if  t==l 

statetime (statecount)=toc ; 

else 

time (count) =toc ; 
count =count+l ; 

end 


end 

disp(  ’ - ’ ) 

disp( ’end’) 

'/, Close  all  relays 
f write (s, 254) 
f write (s, 25) 
fread(s, 1) ; 
f write (s, 254) 
f write (s,0) 
fread(s, 1) ; 
f write (s, 254) 
fwrite(s, 1) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 2) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 3) 
fread(s, 1) ; 
f write (s, 254) 
fwrite(s,4) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 5) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 6) 
fread(s, 1) ; 
f write (s, 254) 
f write (s, 7) 
fread(s, 1) ; 

“/.Sound  to  know  when  the  simulation  stops 

tl=l/10000: 1/10000:2; 

f adtl=(sin(2*pi*369 . 99*tl) ) ; 

sound (f adtl , 10000) 

f close(s) 

delete (s) 

clear  s 
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B  Component  List 


The  main  components  used  in  the  hardware  testbed  are  listed  in  Table  3. 
The  fuses,  which  are  used  by  the  testbed  are  of  type  1  A  3AG  fast  acting 
fuses. 


Quantity 

Product 

1 

USB  Relay  Board  16-Channel  5  Amp  DPDT  8  A/D  Inputs 

2 

12  V  Batteries 

2 

Power  Inverter  12  YDC  to  120  VAC 

2 

Transformers  120  VAC  to  24  VAC 

4 

In  Line  Fuse  Holder  for  3AG  Type 

2 

Rectifier  Units  24  VAC  to  0-5  VDC 

2 

2.4  V  LED  Diodes 

2 

24  VAC  Lamp 

2 

Zener  Diodes 

2 

DPDT  Mechanical  Switches 

2 

AA  Batteries 

1 

AA  Battery  Holder 

Table  3:  List  of  the  components  used  in  the  hardware  testbed. 


